Debugging recommendations for XCode & Swift (iOS)
We recommend that you associate a static identifier with each piece (View or Coordinator) of your project, and use emoji's to symbolize events that can be filtered systematically through the XCode console.
The following article covers our theory of debugging; how to add identifiers, filter or use emoji's to add texture to your debugging. If you are interested in a SwiftLint enabled Swift starter project please download our open source project using the link below.
We advise to use breakpoints when things get messy but these logs should help you achieve faster debugs by layering in prints across your experience.
What debugging events should I add to my application?
We believe that a good mobile application has logs across all events to enable us to ease debugging by verifying that the system is acting accordingly at any point during its creation or maintenance. This suggests that all events, whether touch events, notifications or background tasks, should have logs that tell the story of a users actions.
An example of the logs we use when gathering content.
For example, if your application uses a language coordinator, it should have logs to inform that it initialized, gathered the language and made it available for consumption. In the guards that then test whether the content is available, each guard should inform if the contents not available to let you know where your app is breaking.
An example of how we log camera becoming active or not.
Another example is to confirm if your camera has started or stopped, which could be called at any point in the application and which could be a privacy risk if it doesn't execute every time.
How to add an identifier and filter logs.
Adding a static identifier
An example of a static identifier.
We recommend using a static identifier, so you can filter within guards where self may not be available.
Adding the debug print
An example of how to use your static identifier within a debugPrint.
We recommend using debugPrint as it gives more contextual information than a standard print.
Additionally, the paradigm for logging is:
- An Identifier.
- A function or variable.
- A debugging identifier to inform of whether its in progress, successful, failed, a notification being sent or received.
- Details on the log (i.e. Gathered Content).
For more details on Debugging Identifiers, please read the part below.
Filtering the logs
To filter the logs, add your identifier or associated emoji to the search box within the debug area as shown in the image above.
Using emoji's for textured debugging
We recommend that you use emoji's from emojipedia to add texture to your debugging, by helping you debug specific events such as Notifications being sent or received, along with any userInfo passed; or declaring Success or Failures during operations.
How to create consistent debugging events
We suggest creating a struct, similar to the one above to enable consistency across your application.
We are actively looking for feedback on how to improve this resource. Please send us a note to email@example.com with any thoughts or feedback you may have.