If you want to get a rough idea of the overall design of a project inherited from someone else, if you want to extract and use only part of a large library, or if you want to refactor complicated code, there are class dependencies in the project. I think there are many situations where it is useful to have a panoramic view.
Using a script called objc_dep, you can generate a diagram showing the dependencies of classes in your Xcode project with a single command, as shown below.
I will introduce how to use this script and how to read the generated figure.
If you download it from the following URL and unzip it, you will find a file called objc_dep.py.
https://github.com/nst/objc_dep
Place the script in a suitable location and execute it from the terminal as follows.
$ python objc_dep.py {project path}> {output filename} .dot
For example, if you have a project folder called Demo directly under your home and you want to output with the file name demo.dot,
$ python objc_dep.py ~/Demo > demo.dot
It becomes the command.
The output .dot file can be viewed with the application Graphviz or Omnigraffle. (Omnigraffle is a well-established diagram creation software, but it costs a lot, so if you want to try objc_dep for the time being, I recommend the open source Graphviz.)
Here, I tried to output the dependency of the sample application "Hackbook" that comes with the "Facebook iOS SDK".
Looking at the output figure, there are places that are connected by blue arrows.
According to the comments in the source code, it seems to be connected by a blue arrow when "importing each other".
From the point of view of code maintainability, I would like to avoid class interdependence as much as possible. If a blue arrow is present, it can be used as a refactoring guide, such as using a protocol to consider whether direct references can be made from only one direction.
Also, although it did not appear in this example, a red arrow may appear.
The red arrow means import from a .pch file.
The header imported from the .pch file is referenced by all classes (the arrow for this reference is not drawn), so it seems to be used in this way.
Again, check for unnecessary dependencies, such as importing with .pch but also importing with individual classes, importing classes that should not be imported with .pch, etc. It will be a guideline.
Also not shown in this example, categories are cut out from the dependency diagram (if they are not dependent on other classes) and listed in the upper right corner. By its nature, categories are not a design issue even if they are referenced from many files, so it seems that the specifications are designed so that the figure does not get messed up.