How to detect unused methods and #import in Objective-C
After working a long time on an iPhone app, I realized that my code is quite dirty, containing several #import and methods that are not called or useful at all.
I would like to know if there’s any compiler directive or way to detect those useless lines of code. Does Xcode have any tool to detect this?
- Disable warnings in Xcode from frameworks
- objective c implicit conversion loses integer precision 'NSUInteger' (aka 'unsigned long') to 'int' warning
- Dynamic forwarding: suppress Incomplete Implementation warning
- Xcode: LLVM 7.0: Disable warning “Umbrella header for module does not include header”
- Suppressing line specific XCode compiler warnings
- Property getters and setters
7 Solutions Collect From Internet About “How to detect unused methods and #import in Objective-C”
Xcode allows you to (un)check settings for specific compiler warnings that can warn you of some types of unused code. (Select the project in the source list and File > Get Info, then select the Build tab.) Here are a few (which show up for Clang and GCC 4.2 for me) which may be of interest:
- Unused Functions
- Unused Parameters
- Unused Values
I don’t see any options for detecting unused imports, but that is a bit simpler — the low-tech approach is just to comment out import statements until you get a compile error/warning.
Unused Objective-C methods are much more difficult to detect than unused C functions because messages are dispatched dynamically. A warning or error can tell you that you have a potential problem, but the lack of one doesn’t guarantee you won’t have runtime errors.
Edit: Another good way to detect (potentially) unused methods is to examine code coverage from actual executions. This is usually done in tandem with automated unit testing, but doesn’t have to be.
This blog post is a decent introduction to unit testing and code coverage using Xcode. The section on
gcov (which only works with code generated by GCC, by the way) explains how to get Xcode to build instrumented code that can record how often it has been executed. If you take an instrumented build of your app for a spin in the simulator, then run gcov on it, you can see what code was executed by using a tool like CoverStory (a fairly simplistic GUI) or
lcov (Perl scripts to create HTML reports).
lcov for CHDataStructures.framework and auto-generate coverage reports after each SVN commit. Again, remember that it’s unwise to treat executed coverage as a definitive measure of what code is “dead”, but it can certainly help identify methods that you can investigate further.
Lastly, since you’re trying to remove dead code, I think you’ll find this SO question interesting as well:
- Profiling Objective-C binary image size
Appcode has a code inspection feature which finds unused imports and code.
I recently wrote a script to find unused (or duplicate)
#import statements: https://gist.github.com/Orangenhain/7691314
The script takes an ObjC .m file and starts commenting out each
#import line in turn and seeing if the project still compiles. You will have to change BUILD_DIR & BUILD_CMD.
If you are using a
find command to let the script run over multiple files, make sure to use a BUILD_CMD that actually uses all those files (or you will see a file with lots of unused import statements).
I wrote this without knowing AppCode has a similar feature, however when I tested AppCode it was not as thorough as this script (but way faster [for a whole project]).
As paddydub said, AppCode do this very well. I tried, and it took me just 10 minutes :
Code > Optimize Imports..., or
^ + ⌥ + O
Here is a video describing how to do this : Detection of unused import and methods in AppCode
You can use Xcode Analyser to find that and other problems.
Also you can go to the project and target build and add change warnings preferences under build settings. See this guide:
Recently, I changed a large project from Carbon to Cocoa. At the end of this, there were quite a few orphaned files that were no longer used. I wrote a script to find them that essentially did this:
Ensure the source is all checked in to subversion (ie clean)
Ensure it currently builds without error (ie, xcodebuild returns 0 status)
Then, for each source file in the directory, empty (ie, remove the contents, truncate the length) the source and the header file, try a build, if it fails, revert the files, otherwise, leave them empty.
After running this, revert and then delete all emptied files, compile and then remove all erroring #imports.
I should also add, you need to avoid files that are referenced from .xib or .sdef files, and there may be other dynamic linking cases, but it can still give you a good lead on what can be deleted.
The same technique can be used to see which #imports can be removed – instead of truncating the file, remove each #import in the file in turn and see if the build fails.
- writing events for UIswitch in collection view
- “Application tried to present modally an active controller” Error in iOS5
- Get push notification while App in foreground iOS
- NSAllowsArbitraryLoads not working
- Scratch Card effect in Swift 3
- UIScrollView + Centered View + Ambigous Scrollable Content Size + many iPhone sizes
- @property definitions with ARC: Is strong default now?
- Intercept incoming call ios sdk (Non Jailbreak)
- UILocalNotification does not fire after 10 minutes in background
- Fetching user profile data from LinkedIn in iPhone sdk
- Swift 3 2d array of Int
- locationManager(_:didChangeAuthorization:) executes when app first runs?
- iPhone read/write .plist file
- How to save a uiimageview on top of another uiimageview (swift3)
- TARGET_OS_IPHONE and ApplicationTests