Swift version: 5.1
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.
SAVE 20% ON iOS CONF SG The largest iOS conference in Southeast Asia is back in Singapore for the 5th time in January 2020, now with two days of workshops plus two days of talks on SwiftUI, Combine, GraphQL, and more! Save a massive 20% on your tickets by clicking on this link.
Available from iOS
This is part of the Swift Knowledge Base, a free, searchable collection of solutions for common iOS questions.