turing complete with a stack of 0xdeadbeef
Large Xcode projects can be difficult to navigate, especially when you are making a large change across a large number of files. Depending on how your project is configured, modified files will be spread across multiple nested directories and multiple targets.
When debugging a large project in Xcode that a large team works on, the console can get quite busy. Logs are everywhere! It can be difficult to sift through the noise, particularly when you have a number of breakpoints configured to log messages, execute debugger commands, and continue after evaluating rather than pause.
In my previous post, I explained how to use symbolic breakpoints to discover when view controllers load their views into memory. Often breakpoints are specific to a project. You’ll create one for a specific class that only exists for that particular app. However, what I discussed in that post would be useful in any project. Unlike regular breakpoints, symbolic breakpoints (at least when set on system frameworks) are more or less universal.
Lately, it feels like every few days someone is sharing a new Xcode tip on Twitter or on their blog. They range from hidden settings to features I simply never knew about. I started saving links and planned to add a new “Xcode tips” section to my TIL repo on GitHub to reference later. But as I started, I realized that the resulting markdown file would not be easily discoverable or shareable. I thought, wouldn’t it be nice if the iOS and macOS developer community had a single place to find and share Xcode tips?
Xcode has a great UI for setting and editing breakpoints. I use breakpoints all the time while working and debugging, but I want to share another, unconventional way that I use them.
I recently discovered a preference in Xcode’s Navigation settings that makes the ‘Assistant Editor’ much more useful, especially when writing Swift.