When you build your project, what makes a framework usable is a two-stage process. You first import the framework's header in order to compile and it must link to the framework's binary so that they can interact with each other during runtime.
But, how am I allowed to use the Apple's frameworks by only importing them and not linking them in to your target in the Build Phase ?
For example, I've seen some people manually add MapKit to the Link Binary With Libraries section of Build Phase , but it works perfectly fine without doing so. What is the rule of thumb? Do I ever have to do this process manually? Do I have to make sure to do this for the 3rd party frameworks?
But, how am I allowed to use the Apple's frameworks by only importing them and not linking them in to your target in the Build Phase ?
For example, I've seen some people manually add MapKit to the Link Binary With Libraries section of Build Phase , but it works perfectly fine without doing so. What is the rule of thumb? Do I ever have to do this process manually? Do I have to make sure to do this for the 3rd party frameworks?
As a rule of thumb, it's a good idea to make the linkage explicit in the project setup. This way, you have consistency in the across all scenarios, as the auto-link discovery process doesn't cover every scenario.
The default Xcode project build settings enables module support (CLANG_ENABLE_MODULES) and auto-link of those modules (CLANG_MODULES_AUTOLINK), so that when you use either @import MapKit or #import <MapKit/MapKit.h>, the linker sees that as a module reference and can automatically link the right framework in the SDK.
Not every environment supports modules. For example, if you're working with Objective-C+ +, you can't compile with module support enabled, because C++ does not support modules. If you're linking in third-party frameworks, they also might not be discovered automatically, depending on how the framework vendor expects you to set up the Xcode integration with their library.
Even in environments that do support modules, a project can wind up having implicit dependencies that relies on the auto-link behavior, only to find yourself with a build error because you broke the implicit chain of things that were auto-linked with a big code refactor.
All of those scenarios are where my rule-of-thumb comes in — always adding the linkage explicitly covers all of these scenarios and avoids problems when you do that big refactor or you need to add C++ in a sizable project.
The default Xcode project build settings enables module support (CLANG_ENABLE_MODULES) and auto-link of those modules (CLANG_MODULES_AUTOLINK), so that when you use either @import MapKit or #import <MapKit/MapKit.h>, the linker sees that as a module reference and can automatically link the right framework in the SDK.
Not every environment supports modules. For example, if you're working with Objective-C+ +, you can't compile with module support enabled, because C++ does not support modules. If you're linking in third-party frameworks, they also might not be discovered automatically, depending on how the framework vendor expects you to set up the Xcode integration with their library.
Even in environments that do support modules, a project can wind up having implicit dependencies that relies on the auto-link behavior, only to find yourself with a build error because you broke the implicit chain of things that were auto-linked with a big code refactor.
All of those scenarios are where my rule-of-thumb comes in — always adding the linkage explicitly covers all of these scenarios and avoids problems when you do that big refactor or you need to add C++ in a sizable project.
