Answers:
Xcode允许您（取消）检查特定编译器警告的设置，这些警告可以警告您某些类型的未使用代码。（在源列表中选择项目，然后在“文件”>“获取信息”中选择项目，然后选择“构建”选项卡。）以下是一些您可能感兴趣的内容（对我来说，这对Clang和GCC 4.2来说是这样）。
我看不到用于检测未使用的导入的任何选项，但这有点简单-技术含量低的方法只是注释掉导入语句，直到出现编译错误/警告为止。
未使用的Objective-C方法比未使用的C函数要难得多，因为消息是动态分配的。警告或错误可以告诉您您有潜在的问题，但是缺少警告或错误并不能保证您不会遇到运行时错误。
编辑：检测（潜在）未使用方法的另一种好方法是从实际执行中检查代码覆盖率。通常，这与自动单元测试协同进行，但不是必须如此。
这篇博客文章很好地介绍了使用Xcode进行单元测试和代码覆盖。上的部分gcov（仅与GCC生成的代码一起使用）说明了如何使Xcode生成可记录执行频率的检测代码。如果您在模拟器中使用经过测试的应用构建版本，然后在其上运行gcov，则可以使用CoverStory（一种相当简单的GUI）或lcov（Perl脚本来创建HTML报告）之类的工具来查看执行了哪些代码。。
我在每次SVN提交后都使用gcov和lcov用于CHDataStructures.framework并自动生成覆盖率报告。再次提醒您，将执行覆盖率作为确定哪些代码“死机”的绝对度量是不明智的，但它无疑可以帮助您确定可以进一步研究的方法。
最后，由于您正在尝试删除无效的代码，因此我认为您也会发现这样的SO问题：
我们一直在使用一些本地的Ruby代码，现在将其提取到名为fui的gem中：https : //github.com/dblock/fui
我最近写了一个脚本来查找未使用的（或重复的）#import语句：https : //gist.github.com/Orangenhain/7691314
该脚本获取一个ObjC .m文件，并开始#import依次注释掉每一行，并查看项目是否仍在编译。您将必须更改BUILD_DIR和BUILD_CMD。
如果使用find命令让脚本在多个文件上运行，请确保使用实际使用所有这些文件的BUILD_CMD （否则您将看到一个文件，其中包含许多未使用的import语句）。
我在编写此代码时并不知道AppCode具有类似的功能，但是当我测试AppCode时，它不如该脚本那么详尽（但对于整个项目而言，速度要快得多）。
正如paddydub所说，AppCode可以做到这一点。我尝试了一下，只花了10分钟：
前往Code > Optimize Imports...或^ + ⌥ + O
这是描述如何执行此操作的视频：检测未使用的导入和AppCode中的方法
您可以使用Xcode Analyzer查找该问题以及其他问题。
http://help.apple.com/xcode/mac/8.0/#/devb7babe820
您也可以转到项目并以构建为目标，并在构建设置下添加更改警告首选项。请参阅本指南：
http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/
最近，我将一个大型项目从Carbon更改为Cocoa。最后，有许多不再使用的孤立文件。我编写了一个脚本来查找本质上是这样做的：
确保将源全部签入到Subversion中（即清除）确保其当前正在生成且没有错误（即xcodebuild返回0状态）。然后，对于目录中的每个源文件，将其清空（即删除内容，截断长度）源和头文件，请尝试构建，如果失败，请还原文件，否则，将它们留空。
运行此命令后，还原并删除所有清空的文件，编译然后删除所有错误的#imports。
我还应该补充一点，您需要避免从.xib或.sdef文件引用的文件，并且可能会有其他动态链接情况，但是它仍然可以为您提供可删除内容的良好线索。
可以使用相同的技术来查看可以删除哪些#imports-而不是截断文件，而是依次删除文件中的每个#imports并查看构建是否失败。
id或创建选择器以在运行时调用，则静态分析器无法保证该代码是真正未使用的。如果仍然需要的代码被删除，那将是运行时错误的地方。我想念什么吗？