Breakpoints are indispensable for debugging problems in a software project. Debugging an app with breakpoints can seem complex at first, but it isn't difficult once you understand what is going on. While the underlying concept of debugging with breakpoints is simple, you can make it as complex as you want to fit your needs.
Many developers use breakpoints to debug problems, but a surprising number doesn't understand what they are and how they work under the hood. Let me start by answering the question what is a breakpoint?
A breakpoint gives you the ability to pause or interrupt an app's process based on a set of predefined conditions. The debugger breaks the app's process when it hits a breakpoint hence the name.
Breakpoints are set in the debugger. Developers that are unfamiliar with breakpoints wrongly assume that breakpoints need to be removed or disabled in release builds. That isn't correct, though. The breakpoints you set in the debugger are not part of the builds the compiler creates.
You can only debug an app with breakpoints if the app is attached to the debugger. A user who downloads your app from the App Store or TestFlight won't run into the breakpoints you set in development because the app isn't attached to the debugger. And, as I mentioned earlier, breakpoints are set in the debugger, they are not included in the builds you upload to App Store Connect.