Debugging recommendations for XCode & Swift (iOS)

Oscar de la Hera Gomez
A flower that represents Swift next to a flower that represents XCode. Beneath it sits the text that states 'Debugging Recommendations'.

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?

A picture of a magnifying glass over a bug.

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.

A screenshot of our language coordinator and how it gathers content.

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.

A screenshot showing events logged when starting or stopping the camera.

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

A screenshot showing how to add a static identifier in Swift in XCode.

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

A screenshot showing how to add a debugPrint with a static identifier.

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

A screenshot showing how to filter 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

A range of emojis.

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

A screenshot of our suggested debugging identifiers.

We suggest creating a struct, similar to the one above to enable consistency across your application.

Any Questions

We are actively looking for feedback on how to improve this resource. Please send us a note to with any thoughts or feedback you may have.

delasign logo

Book a Free Consultation.

An icon of an email.

Click here to email us.

Fill in the details below to book a free consultation or to let us know about something else. Whatever it is, we are here to help.

How can we help you ?

Contact Details