How to debug iOS Notification Service Extension

Marta
Marta
Feb 19 · 3 min read

In mobile department we are updating our notifications and we have found some problems when we wanted to debug our code in extension when push notification is received. First of all, I’m going to explain the two typical ways to solve it:

On the one hand, you have to change the target to run the extension:

After run, you have to choose your app from the “Choose an app to run” window.

After that, the App is launched and when a push notification is received the breakpoint will be working.

On the other hand, you can use Xcode’s Debug > Attach to Process > By Process Identifier (PID) or Name… menu: you can provide the name of your process and Xcode will wait until it launches to attach and start a debug session.

In addition, I’m going to explain another way to know what’s happening in your extension when a push notification is received and your app is terminated, I’m going to speak about logs.

Logs

When we are programming we can easily read logs from Xcode debug console, because the debugger only shows current application logs and nothing else. Logs are easy to read. But in our case if we had problems with breakpoints we’ll have the same problem (the logs aren’t going to be printed) with logs from Xcode debug, so we are going to write in the device console. But now, probably, you are worried because there are a lot of OS log outputs per second in device console😖. It’s not a problem because with the os.log framework we are going to filter the logs in the console 💪.

It’s easy to use. In the first place you have to import the framework in your extension.

import os.log

Then, we only have to call os_log() function with different parameters. It looks like this:

os_log("%{public}@", log: OSLog(subsystem: bundleIdentifier, category: "myExtension"), type: OSLogType.debug, "Push received!")

But…what is every parameter?🔦. Let’s see💡:

  • The first parameter is the access level for each message. If it isn’t provided, it’s treated as a private. If it’s private the value isn’t printed if application does not have Xcode Debugger attached to it.
  • The second parameter is a list of parameter that we can use to filter the messages in the device console.
  • The third parameter indicates the different type for log messages (debug, info, error, etc). By default, Console is hiding debug log messages, so you need to enable them in the Console > Action menu if you want it.
  • The last parameter is whatever you want to print.

If we try the example we can see this message in the device console when we receive a push notification although the application is in background or terminated.

Finally, we can see that we have different ways to see what is happening in our extension when push notification is received. Given the three options you choose the one that suits you best 😃

Tiendeo Tech

Code, thoughts and solutions — www.tiendeo.com

Marta

Written by

Marta

Tiendeo Tech

Code, thoughts and solutions — www.tiendeo.com