Xcode has lots of tools to help you debug user interface problems, but it’s a little tricker to debug things you can’t see – network requests failing, data loading code going wrong, and so on.
A few years ago Markos Charatzas gave a pioneering talk at NSConference about the importance of using sound for debugging, and it’s a concept I’ve since used in my own projects.
To try it out, place a breakpoint somewhere in your code, then right-click on it and choose “Edit Breakpoint”. Click the Add Action button, then change the action to be “Sound” – you’ll see a list of system sounds you can choose from.
It doesn’t matter which sound you choose (although having sad sounds for failures does help!), but no matter what you decide you should check the box below marked “Automatically continue after evaluating actions” – this will ensure your breakpoint doesn’t stop execution of the program.
That checkbox plus the sound together means your program won’t pause when your breakpoints are hit, but will instead almost become musical: as network operations start, succeed, or fail, you’ll hear beeps, clicks, and bongs from your Mac so you’ll know exactly what’s happening just by listening.
Note: In case you were worried, none of these sounds will actually play when your app ships – they are just used by Xcode’s debugging engine.
Available from iOS
Did this solution work for you? Please pass it on!
Other people are reading…
About the Swift Knowledge Base
This is part of the Swift Knowledge Base, a free, searchable collection of solutions for common iOS questions.
Need to know Objective-C fast?
I wrote a book dedicated to teaching Objective-C to developers who already know Swift – it's the fastest way to get up to speed!