Chapters
Chapters

Chapters

Hide chapters

Advanced Apple Debugging & Reverse Engineering

Fourth Edition · iOS 16, macOS 13.3 · Swift 5.8, Python 3 · Xcode 14

Before You Begin

Section 0: 6 chapters
Show chapters Hide chapters

Section I: Beginning LLDB Commands

Section 1: 10 chapters
Show chapters Hide chapters

Section II: Understanding Assembly

Section 2: 3 chapters
Show chapters Hide chapters

Section III: Low Level

Section 3: 6 chapters
Show chapters Hide chapters

Section IV: Custom LLDB Commands

Section 4: 8 chapters
Show chapters Hide chapters

Section V: DTrace

Section 5: 3 chapters
Show chapters Hide chapters

Appendices

Section 6: 3 chapters
Show chapters Hide chapters

4. Stopping in Code
Written by Walter Tyree

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Whether you’re using Swift, Objective-C, C++, C, or an entirely different language in your technology stack, you’ll need to learn how to create breakpoints. It’s easy to click on the side panel in Xcode to create a breakpoint using the GUI, but the lldb console can give you much more control over breakpoints.

In this chapter, you’re going to learn all about breakpoints and how to create them using LLDB.

Signals

For this chapter, you’ll be looking at an Xcode project called Signals which you’ll find in the resources bundle for this chapter.

Open up the Signals starter project using Xcode. Signals is a basic primary-detail project themed as an American football app that displays some rather nerdily-named offensive play calls.

The app monitors several Unix signals, handles them when received and displays them in a list.

Unix signals are a basic form of interprocess communication. For example, one of the signals, SIGSTOP, can be used to save the state and pause execution of a process, while its counterpart, SIGCONT, is sent to a program to resume execution. Both of these signals can be used by a debugger to pause and continue a program’s execution.

Signals is an interesting application on several fronts, because it not only explores Unix signal handling, but also highlights what happens when a controlling process (lldb) handles the passing of Unix signals to the controlled process. By default, lldb has custom actions for handling different signals. Some signals are not passed onto the controlled process while lldb is attached.

In order to display a signal, you can either raise a Signal from within the application, or send a signal externally from a different application, like bash running in Terminal.

In addition, there’s a UISwitch that toggles the signal handling. When the switch is toggled, it calls a C function sigprocmask to enable or disable the signal handlers that the Signals app is listening to.

Finally, the Signals application has a Timeout bar button which raises the SIGSTOP signal from within the application, essentially “freezing” the program. However, if lldb is attached to the Signals program (and by default it will be, when you build and run through Xcode), calling SIGSTOP will allow you to inspect the execution state with lldb while in Xcode.

Build and run the app on your preferred iOS Simulator running iOS 16 or greater. Once the Signals project is running, navigate to the Xcode console and pause the debugger.

Resume Xcode by clicking the same button you used to pause and keep an eye on the Simulator. A new row will be added to the UITableView whenever the debugger stops then resumes execution. This is achieved by Signals monitoring the SIGSTOP Unix signal event and adding a row to the data model whenever it occurs. When a process is stopped, any new signals will not be immediately processed because the program is sort of, well, stopped.

Xcode Breakpoints

Before you go off learning the cool, shiny breakpoints through the lldb console, it’s worth covering what you can achieve through Xcode alone.

lldb Breakpoint Syntax

Now that you’ve had a crash course in using the IDE debugging features of Xcode, it’s time to learn how to create breakpoints through the lldb console. In order to create useful breakpoints, you need to learn how to query what you’re looking for.

Objective-C Properties

Learning how to query loaded code is essential for learning how to create breakpoints on that code. Both Objective-C and Swift have specific naming conventions when code is generated by the compiler. This is known as name mangling.

Objective-C Properties and Dot Notation

Something that is often misleading to entry level Objective-C (or Swift only) developers is the Objective-C dot notation syntax for properties.

Swift Properties

The syntax for a property is much different in Swift. Take a look at the code in SwiftTestClass.swift which contains the following:

Finally… Creating Breakpoints

Now that you know how to query the existence of functions and methods in your code, it’s time to start creating breakpoints on them.

Regex Breakpoints

Another extremely powerful command is the regular expression breakpoint, rbreak, which is an abbreviation for breakpoint set -r %1. You can quickly create many breakpoints using smart regular expressions to stop wherever you want.

Breakpoint Scope

You can limit the scope of your breakpoints to a certain file, using the -f option. For example, you could type the following:

Other Cool Breakpoint Options

The -L option lets you filter by source language. So, if you wanted to only go after Swift code in the Commons module of the Signals project, you could do the following:

Breakpoint Actions

You can also perform actions when suspended on a breakpoint in lldb just like using Xcode’s Symbolic Breakpoint window.

Modifying and Removing Breakpoints

Now that you have a basic understanding of how to create these breakpoints, you might be wondering how you can alter them. What if you found the object you were interested in and wanted to delete the breakpoint, or temporarily disable it? What if you need to modify the breakpoint to perform a specific action next time it triggers?

Key Points

  • The Breakpoint Navigator in Xcode is a wrapper around many of the console breakpoint commands.
  • Symbolic Breakpoints can be set on symbols in your app or in any loaded library.
  • Use image lookup with the -n or -rn switches to find out where a symbol is defined.
  • The compiler synthesizes getters and setters for properties at runtime, so sometimes you have to launch an app before you can set breakpoints.
  • rbreak is an abbreviated command for breakpoint set -r that lets you use regular expressions to match symbol names to breakpoint on.
  • The -s and -f switches on breakpoint set allow you to constrain how many locations are included in a breakpoint.
  • The -p switch allows you to set a breakpoint on an expression in your source code.
  • The read and write subcommands of breakpoint allow you to export and import breakpoints into .json files for sharing or saving.
  • The breakpoint list and breakpoint delete commands take breakpoint ID numbers or ranges to constrain their actions.

Where to Go From Here?

You’ve covered a lot in this chapter. Breakpoints are a big topic and mastering the art of quickly finding an item of interest is essential to becoming a debugging expert. You’ve also started exploring function searching using regular expressions. Now would be a great time to brush up on regular expression syntax, as you’ll be using lots of regular expressions in the rest of this book.

3. Attaching With LLDB
5. Expression
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now