Swift version: 5.4
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.
SPONSORED With Sentry’s error and performance monitoring for iOS, you see mobile vitals that actually matter, can solve any latency issues quickly, and learn how each release is performing over time.
Available from iOS
This is part of the Swift Knowledge Base, a free, searchable collection of solutions for common iOS questions.
Link copied to your pasteboard.