Question

TL;DR Version:

This question has arisen due to the fact that I have multiple frameworks (which I have built) and a client project that uses said frameworks. Now, when I open up the client project and try to debug into the framework, it doesn’t work.

However, if I have the project associated with the framework open, then debugging appears to work (though there are some weird issues with breakpoints I don’t see being triggered).

I have looked at Apple’s docs, and perhaps the answer is buried there somewhere, but I couldn’t find it on a skim of the Xcode Debugging Guide.

Long Version:

The reason this question is important to me is that a coworker and I had a disagreement about how headers are imported in the frameworks we build.

I have a tendency to use framework headers (with client apps) in the fashion:

#import "FrameworkA/HeaderA.h"
#import "FrameworkB/HeaderB.h"

He, on the other hand, favors importing the framework headers (with client apps) like this:

#import "HeaderA.h"
#import "HeaderB.h"

and specifying the header search paths in the build target of the client application.

Complicating matters further is the fact that some of these frameworks have interdependencies. For example, FrameworkB has headers from FrameworkA referenced in his format:

#import "HeaderA.h"

His argument for doing this is that debugging only works if we import headers this way. It seems dubious to me that there would be a relation between header importing style and debugging, but I am not really certain how XCode chooses the file to link to during debugging, hence the question.

Thanks in advance for any assistance with this query.

Answer 1

you add project references to the target, and make sure Xcode knows where to find the debug symbols.

#import <FrameworkA/HeaderA.h>

that’s the way to go (for internal and external declarations). the reason? the other approach is more likely to cause issues as libraries evolve. the additional qualification disambiguates any case (unless of course there are two FrameworkA/s in your search path), it’s best to qualify the file explicitly now, rather than when your clients tell you they cannot use your library with other libraries, or that they can only use them in some conditions. then you have to go fix the issues and reship (this stuff has a way of happening at inconvenient times =p). it’s one simple measure to ensure you’ve developed a robust interface.

perhaps the most important part that people overlook is the location of the products: use a customized central build location for your targets — many people use the default location, which is by the xcodeproject. otherwise, Xcode may not be able to locate debug information.

finally, debugging complex projects in Xcode can be quite… let’s call it ‘problematic’. So don’t expect the debugging experience to be perfect, even if you’ve configured everything correctly. all the more reason to integrate assertions and unit tests into your development cycle early on with Xcode. truth is, the debugger may be useless no matter how hard you try – this is not a new issue. hopefully LLDB will improve our debugging experiences.

good luck