|It Looks Like You Are Trying to Use a Framework|
The error ‘No such module’ is a common compile time error. It notifies that the compiler was unable to locate the public header files for the third party module name being imported.
In Xcode, select target, then in its Build Phase\ settings, add the ‘No such module’ to the ‘Links Binary with Libraries’ settings.
The module names added to ‘Links Binary with Libraries’ setting will instruct the compiler to compile and build each of the given dependent module.
The compiled binary libraries, along with their public header files, will be copied over to the the ‘derived data folder’.
The ‘derived data folder’ is the default Xcode output folder for all compile and build operations for your project, including the main application code.
The import error will still persist until this second step is added.
In Xcode, select the framework target, then add the following to the setting path Build Settings -> Search Paths\ -> Framework Search Paths\
The $(BUILD_PRODUCTS_DIR)\ is a property that resolve to the build output folder, i.e. the derived data folder. These additions tells the compiler to look at the derived data folder to resolve the import references to the said third party libraries.
After successful compilation, running the main app which includes these levels of frameworks will generate loading errors if the linkage is not set up right.
This commonly comes in the form of a ‘dyld: Library not loaded\’ error message in the output log.
The compilation stage creates for each first and third party framework modules their binary representation. Those binary libraries don’t know the presence or location of each other.The dynamic linkage operation performs that task. It tells each library where, in memory space, to look for other libraries it depends on.
To fix the problem the first interpretation needs to be resolved. The list of paths the linker searches for are declared in this framework’s target setting: Build Setting\ -> Linking\ -> Runpath Search Paths\
Its settings value should open up a list of paths. This is where dyld\ looks for the location of libraries to load.
Here, in addition to the standard system libraries, append the dependent third party frameworks. The property $(BUILT_PRODUCTS_DIR)\ will resolve to the sub-root folder of where all libraries are compiled to, the derived data folder.