The Problem With Print Statements

In mobile application development, it’s important to have a way to see the things you can’t normally see when your application is running, as it so happens when you run any application you’ve downloaded from the App Store. There are times when you want to see what’s happening under the hood in your own application, most especially during development and creating bug fixes. There are some perfectly fine examples of why you would want to print to the console, such as:

• To check for logic errors
• To verify the application executes statements through a segment of code
• To print out values of objects at various points in the application

Many times, print statements can be strategically replaced with conditional breakpoints that fire only in an undesirable condition while the application is running in Debug mode. Sometimes, you just need a freaking print statement to execute to the console! And, you are a smart mobile developer, so you know that print statements are valid code that will execute in Release and Debug modes, so you don’t want to impact processor performance when you release your app into the wild, so you decide to check the Build Configuration of the application before printing anything to the console…or at least, that’s what you are hear to learn how to do!

print("This will take CPU resources in Release mode.")

Printing In Debug Only!

Out of the box, Xcode provides two build configurations:

• Debug
• Release

You are more than welcome to add additional build configurations to your project. If you are working solo, then Debug and Release may be enough for you. Otherwise, you may need additional configurations such as:

• Test/QC
• User Tests
  
• Testing Push Notifications
• Connected With Apple Watch

Your company’s Software Development Life Cycle (SDLC) will dictate what you will need. If you are the one coming up with your SDLC, then throw everything in there (if it makes sense for the project) and scale back as you get in your groove and determine what the company/project really needs.

The plan is simple, we just simply need to check if the environment is in DEBUG or not. If you have experience developing in Objective-C, then this should look very familiar:

/// Prints to the console when application is in DEBUG only.
/// - Parameter filter: String, Label to be used to filter out console output.
/// - Parameter message: String, the content to be output to the console.
func debugPrint(filter: String, message: String) {
    #if DEBUG
    print("\(filter): \(message)")
    #endif
}

The key here is

#if DEBUG

With that simple qualifier, you eliminate the worry of printing something to the console when your code is in a production environment/Release build. That means, your application will run faster, take up less CPU resources, and be better at whatever you made the app do. Happy coding!