If you mutate myObj.name using the setter, you can add a symbolic breakpoint on -[MyObjClass setName:] either from the Debugger Console or from the Run->Manage Breakpoints->Add Symbolic Breakpoint menu in Xcode. If not (why not? you probably shouldn't be modifying the instance variable directly except in the designated initializer or dealloc) you can set a watchpoint in gdb (use the Debugger Console in Xcode once the debugger is running). This page explains how. I don't believe Xcode exposes a UI for setting watchpoints without using the Debugger Console.
You can set a conditional break point in Xcode by setting the breakpoint normally, then control-click on it and select Edit Breakpoint (choose Run -> Show -> Breakpoints).
In the breakpoint entry, there is a Condition column.
Now, there are several issues to keep in mind for the condition. Firstly, gdb does not understand dot syntax, so instead of myObj.name, you must use [myObj name] (unless name is an ivar).
Next, as with most expressions in gdb, you must tell it the type of return result, namely "BOOL". So set a condition like:
(BOOL)[[myObj name] isEqualToString:@"Bar"]
Often it is actually easier to just do this in code by temporarily adding code like:
if ( [myObj.name isEqualToString:@"Bar"] ) {
NSLog( @"here" );
}
and then setting the break point on the NSLog. Then your condition can be arbitrarily complex without having to worry about what gdb can and can't parse.
At times when working with Frameworks (debug builds) and need to put a breakpoint in certain file/location that is hard to navigate or isn't exposed publically in framework under development. One option is to write a helper class to trigger conditional breakpoints & make step-in/step-out easier.
Here is how you do using XCode lldb conditional breakpoints.
First, double click the breakpoint (or right-click edit breakpoint), you can see a dialogue popup.
Updated 2021-04-22 for Xcode 12:
Here is what these options means:
Condition: The breakpoint will only fire under this condition.
Ignore: The amount of times the condition needs to meet before fire the breakpoint
Action: Action that runs after the breakpoint breaks.
Options: Automatically continue after evaluating actions
Here is a summary. For the above example in the image, it means that when the variable testedString is equal to "Testing", break here. If I add ignore time to 1, then it will ignore the first time when testedString is equal to "Testing" and break at the second time the condition is met.
For actions, when you press add actions, there will be a list of choices. Usually what I do is to use the Debugger Commandpo to print variables that I need to check and I believe that there are better ways using the actions than I do.
It seems that you have to recompile and run the app if you change the conditions at runtime