[ACCEPTED]-How to detect unused methods and #import in Objective-C-compiler-warnings

Xcode allows you to (un)check settings for 40 specific compiler warnings that can warn 39 you of some types of unused code. (Select 38 the project in the source list and File 37 > Get Info, then select the Build tab.) Here 36 are a few (which show up for Clang and GCC 35 4.2 for me) which may be of interest:

• Unused Functions
• Unused Parameters
• Unused Values

I don't 34 see any options for detecting unused imports, but 33 that is a bit simpler — the low-tech approach 32 is just to comment out import statements 31 until you get a compile error/warning.

Unused 30 Objective-C methods are much more difficult 29 to detect than unused C functions because 28 messages are dispatched dynamically. A warning 27 or error can tell you that you have a potential 26 problem, but the lack of one doesn't guarantee 25 you won't have runtime errors.

Edit: Another good 24 way to detect (potentially) unused methods 23 is to examine code coverage from actual 22 executions. This is usually done in tandem 21 with automated unit testing, but doesn't 20 have to be.

This blog post is a decent introduction to 19 unit testing and code coverage using Xcode. The 18 section on gcov (which only works with code 17 generated by GCC, by the way) explains how 16 to get Xcode to build instrumented code 15 that can record how often it has been executed. If 14 you take an instrumented build of your app 13 for a spin in the simulator, then run gcov 12 on it, you can see what code was executed 11 by using a tool like CoverStory (a fairly simplistic 10 GUI) or lcov (Perl scripts to create HTML reports).

I 9 use gcov and lcov for CHDataStructures.framework and auto-generate coverage reports after 8 each SVN commit. Again, remember that it's 7 unwise to treat executed coverage as a definitive 6 measure of what code is "dead", but 5 it can certainly help identify methods that 4 you can investigate further.

Lastly, since 3 you're trying to remove dead code, I think 2 you'll find this SO question interesting 1 as well:

• Profiling Objective-C binary image size

Appcode has a code inspection feature which finds 1 unused imports and code.

We've been using some homegrown Ruby code, now 1 extracted into a gem called fui: https://github.com/dblock/fui

As paddydub said, AppCode do this very well. I tried, and 2 it took me just 10 minutes :

Go to Code > Optimize Imports..., or ^ + ⌥ + O

Here 1 is a video describing how to do this : Detection of unused import and methods in AppCode

I recently wrote a script to find unused 13 (or duplicate) #import statements: https://gist.github.com/Orangenhain/7691314

The script takes 12 an ObjC .m file and starts commenting out 11 each #import line in turn and seeing if the project 10 still compiles. You will have to change 9 BUILD_DIR & BUILD_CMD.

If you are using 8 a find command to let the script run over multiple 7 files, make sure to use a BUILD_CMD that 6 actually uses all those files (or you will see 5 a file with lots of unused import statements).

I 4 wrote this without knowing AppCode has a 3 similar feature, however when I tested AppCode 2 it was not as thorough as this script (but 1 way faster [for a whole project]).

You can use Xcode Analyser to find that 4 and other problems.

http://help.apple.com/xcode/mac/8.0/#/devb7babe820

Also you can go to the 3 project and target build and add change 2 warnings preferences under build settings. See 1 this guide:

http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/

Recently, I changed a large project from 23 Carbon to Cocoa. At the end of this, there 22 were quite a few orphaned files that were 21 no longer used. I wrote a script to find 20 them that essentially did this:

Ensure the 19 source is all checked in to subversion (ie 18 clean) Ensure it currently builds without 17 error (ie, xcodebuild returns 0 status) Then, for 16 each source file in the directory, empty 15 (ie, remove the contents, truncate the length) the 14 source and the header file, try a build, if 13 it fails, revert the files, otherwise, leave 12 them empty.

After running this, revert and 11 then delete all emptied files, compile and 10 then remove all erroring #imports.

I should 9 also add, you need to avoid files that are 8 referenced from .xib or .sdef files, and 7 there may be other dynamic linking cases, but 6 it can still give you a good lead on what 5 can be deleted.

The same technique can be 4 used to see which #imports can be removed 3 - instead of truncating the file, remove 2 each #import in the file in turn and see 1 if the build fails.