Pro Mode

The features described below require a license in order to be used. You may purchase your license here.

Activating Pro Mode

To activate Pro Mode you'll need the license key emailed to you after purchase. The email contains your email address and license key, these must be entered into Periphery exactly as they are in the email.

To activate using an interactive prompt:

periphery activate

Alternatively, you can activate non-interactively by passing the --email and --key options to activate.

Aggressive Analysis

By default Periphery aims to only report declarations that are safe to remove. In practice however, there are some scenarios in which code has a very high likelihood of being unused, but which cannot be guaranteed by static analysis alone. Such analysis techniques that may produce false negatives must be enabled explicitly.

To enable aggressive analysis:

periphery scan --aggressive ...
More scrutiny is advised when reviewing results produced by aggressive analysis. Some results may appear at first glance to be unused, and indeed your application may compile successfully after removal, however you should keep in mind how the removal might affect dynamic runtime behavior. With great power comes great responsibility!

The following scenarios are identified with aggressive analysis:

Reusing Build Logs

In order to understand what reusing a build log means exactly, you first need to understand a little about how Periphery works, or more specifically, how SourceKit works. Periphery uses SourceKit to 'index' each Swift file, or in other words, translate it into a machine-readable format containing a high degree of detail, and crucially the references between declarations. In order to request this indexed format from SourceKit, Periphery must provide the Swift compiler arguments required to compile the file. In practice, this set of compiler arguments is the same as is needed to build the target which the file is a member of. Frustratingly, SourceKit does not provide an easy way to determine the appropriate compiler arguments needed for any given file. That's why Periphery must build your project - to spy on xcodebuild and extract the arguments passed to the Swift compiler.

Periphery allows you to save build logs so that you may skip the build phase, and jump straight to indexing. This can be a huge time saver while you're iterating on removing unused code, or when using Periphery in a continuous integration environment. To generate a build log, you have two options: allow Periphery to save one, or save your own by redirecting xcodebuild output to a log.

Using Periphery's Build Logs

Pass the --save-build-log <key> option to the scan command, and Periphery will save a build log for you. You can then reuse it with the --use-build-log <key> option. The key can be anything you wish, however it is hashed along with the project, schemes and targets you specify. For example, you cannot save a build log, add another target to the --targets option and attempt to reuse the same build log.

Using Your Own Build Logs

In a situation where you have already just compiled your project, e.g in CI to run tests, you can save yourself some time by passing the build log to Periphery. In order to do so, you'll need to redirect the output of xcodebuild to a file You need to be sure that the xcodebuild command builds all of the targets that you're then going to ask Periphery to analyze, otherwise Periphery will complain about missing build arguments. If your build process requires multiple calls to xcodebuild, just append the output to the same file. Once you have the build log, you can instruct Periphery to use it by passing the --use-build-log <path to log> option to the scan command. The build log must have a .log extension to distinguish it from a <key> as described above.

Important - must read!

The build log contains highly specific references to DerivedData. Any modification to DerivedData after saving the build log, and before using it with Periphery is likely to invalidate the build log. Periphery will warn you as such if this has happened. Therefore, reusing build logs is only suitable for situations where you intend to use the log immediately after it has been generated. You cannot save a build log on one machine and reuse it on another, as SourceKit depends upon the contents of DerivedData to index files.

Excluding Files

Both exclusion options described below accept a path glob, either absolute or relative to your project directory. You may specify multiple globs by separating them with a pipe character, e.g "Foo.swift|{Bar,Baz}.swift|path/to/*.swift". Recursive (**) globs are not supported at this time.

Excluding Results

To exclude the results from certain files, pass the --report-exclude <globs> option to the scan command.

Excluding Indexed Files

To exclude files from being indexed, pass the --index-exclude <globs> option to the scan command. Excluding files from the index phase means that any declarations and references contained within the files will not be seen by Periphery. Periphery will be behave as if the files do not exist. This option can be used to exclude generated code that holds references to non-generated code.


As well as the default Xcode output format, Pro Mode also supports JSON and CSV formats. Both formats provide more detailed information about each result than the Xcode format. To use an alternate format, pass the --format <name> option to the scan command, where <name> is one of xcode, json or csv.

Purchase Pro Mode