Debugging recommendations for XCode & Swift (iOS)

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.

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.

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.

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.

We recommend using a static identifier, so you can filter within guards where self may not be available.

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.

To filter the logs, add your identifier or associated emoji to the search box within the debug area as shown in the image above.

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.

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 inquiries@delasign.com with any thoughts or feedback you may have.