C Language Family Front-end

Extension: Unsafe API Checks (iOS & Mac applications only)

Deprecation Notice

This project is not maintained and may include outdated information or code that is not compatible with recent versions of tools, such as, Xcode and Clang. The repository is online for reference only.

If you are interested in this project, you may want to read this brief answer on Stackoverflow, detailing the current state of affairs. If you speak German, you can download & read my diploma thesis in full. Please keep in mind that it was written in 2013, any many things (Swift, Clang, Xcode,...) have changed since it was published.

Information on how to use custom (or bleeding edge) Clang versions in Xcode is summarized in these Stackoverflow posts:

For current projects, please visit my GitHub or Stackoverflow profiles.


This extension brings support to detect so-called unsafe APIs, or critical APIs. Any API that was introduced later than the current deployment target (minimum runtime version) is considered unsafe as it may not be available on all platforms that the app promises to support.

The extension has been developed for iOS applications and should work, but has not been tested, for Mac applications as well. It relies on availability information that Apple provides using availability macros in the framework headers. The extension is not cross-platform compatible as it dynamically links the Foundation framework that ships with Mac OS X only.

It supports the detection of these types of (critical) symbols and APIs:

  • Objective-C methods, including the usage of performSelector:
  • Objective-C classes and superclasses
  • C functions
  • String constants that are declared extern

By default (i.e., on branch customised_clang), the extension does not raise warnings nor does it export any information. Use these flags to generate warnings and output:

  • -Wunsafe-api-usage: Show warnings for all supported unsafe symbols
  • -export-api-usage: Export (un)availability information of all critical symbols to a PLIST file within the build directory
  • -Wfix-unsafe-api-usage: Suggest fixes. Not recommended for general purpose usage as it relies on conventions from another project.
  • -Wunfixable-api-usage: Only show warnings that the above-mentioned project cannot resolve

Note: Settings custom warning flags may cause compatibility issues with Xcode (it breaks autocomplete, unless you overwrite the default clang binary and libClang.dylib in Xcode's default Toolchain: /Applications/

To allow the use of this customised version simply by setting the CC flag (leaving the existing toolchain untouched), two branches with different sets of default-enabled warnings have been created:

  • customised_clang_detection: Enable -Wunsafe-api-usage by default.
  • customised_clang_resolution: Enable -Wfix-unsafe-api-usage and -Wunfixable-api-usage by default.

Builds of both branches and a tool to easily integrate it into your own Xcode project are provided in a separate repository.

Extension developed by Sebastian Hagedorn.

Original Clang README

Welcome to Clang. This is a compiler front-end for the C family of languages (C, C++, Objective-C, and Objective-C++) which is built as part of the LLVM compiler infrastructure project.

Unlike many other compiler frontends, Clang is useful for a number of things beyond just compiling code: we intend for Clang to be host to a number of different source level tools. One example of this is the Clang Static Analyzer.

If you're interested in more (including how to build Clang) it is best to read the relevant web sites. Here are some pointers:

Information on Clang: Building and using Clang: Clang Static Analyzer: Information on the LLVM project:

If you have questions or comments about Clang, a great place to discuss them is on the Clang development mailing list:

If you find a bug in Clang, please file it in the LLVM bug tracker: