How to debug iOS 8 extensions with NSLog?

IosIos8Xcode6Ios App-Extension

Ios Problem Overview


- (void)viewDidLoad
{
    NSLog(@"%s", __func__);
    // ...
}

in viewDidLoad of an iOS 8 extension. the NSLog outputs nothing in Xcode. NSLog works as usual in the container app though.

How can I get output from debug messages from an extension?

Ios Solutions


Solution 1 - Ios

  1. Debugging works for app extensions.

  2. It works on simulator too.

  3. If your app ext crashes in the simulator, you may find it is not easy to restart your app ext. Restarting your simulator is a quick solution.

  4. Steps to debug an app extension:

    1. Run the container app. In this step, Xcode uploads the container app and app extension to the device or simulator.

    2. Stop the container app. This step is important when you debug in simulator. If you don't do it, Xcode will tell you the simulator is in use.

    3. In Xcode, press menu Debug -> Attach to Process -> By Process Identifer (PID) or Name..., input the app ext's identifier, e.g. com.abc.ContainerApp.MyExtension, to start debugging. Don't forget to set break points. (Update on Aug 25, 2014: you can input MyExtension(your extension's name) directly.)

    4. In the device or simulator, open your app extension.


Updates on Aug 23, 2014:

I found the debugging steps above do not work well on Xcode 6 beta 6 with iOS 8 SDK beta 5 on the simulator.

Solution:

  1. Run your extension in the simulator.
  2. Xcode menu Debug -> Attach to Process -> Choose "MyExtension(your extension's name)" in System section in the menu.

The breakpoints work. But I don't know why logs do not show in the output window.

Solution 2 - Ios

I'm having this problem too. It works for me if you go in your Simulator under the menu Debug -> Open System Log...

From here you can see all the logs of the iPhone Simulator (included your extension's logs).

enter image description here

Solution 3 - Ios

NSLog is working perfectly.

You just don't see what is being logged in the debug area of Xcode because the Xcode debugger isn't attached to your extension. Extensions are nearly completely independent from their containing app. They have separate bundle identifiers, for example, and they also are separate processes on the OS.

I have had varied success in getting Xcode to attach to extensions. Supposedly it seems it would attach automatically, and it appears in the debug navigator as "Waiting to attach", but never attaches.

Sometimes, I am able to run my extension target in Xcode:

enter image description here

And then have the option to choose what application to run my extension in. In this case, I would choose its recommendation of "today", which is notification center.

enter image description here

And then it would sometimes attach the debugger to my extension. Note this method only works on physical devices, it seems.

If it doesn't attach you can use the manual attachment method in @VinceYaun's answer,

I have also had varied success using other methods of attachment. Most have been unsuccessful, and it seems they are just bugs that will be fixed at a later date.

To view your log messages you go to Window -> Devices in the top bar and select your device. You can bring up the device log from the bottom of that window. If you are testing on a simulator, you can use @BalestraPatrick's answer.

Some of the bugs have been fixed in Beta 2, and my guess is that eventually the debugger will attach automagically when launching the extension.

Update: In the iOS 8 Beta 4 release notes:

>

Extensions

>

Fixed in beta 4

> > - Extensions sometimes fail to launch when debugging from Xcode. > - When Extension with UI is killed, it relaunches and is not dismissed. > - Sometimes your Sharing or Action extension can hang. > - Redeploying an extension may disable it in Notification Center.

Solution 4 - Ios

I'm having this problem too. Xcode never attaches my debugger to the extension or displays NSLog messages. If you attach your Xcode debugger manually to your extension process, at least breakpoints work like a charm:

Debug->Attach to process->Your extension name (mine was "com.example.MyExtensionApp.MyExtension")

Solution 5 - Ios

  1. Create scheme for your extension
  2. Run scheme
  3. In a dialog choose container app
  4. Enjoy

It works for me :)

Solution 6 - Ios

Xcode 8 is able to debug extensions:

  1. Choose the extension scheme in the combo next to the stop button and run it.
  2. Select the parent application in the dialog that appears.

Result: breakpoints and log work as usual.

Solution 7 - Ios

What finally allowed me to see the log in the debugging area, based on Michael's suggestion and Apple's documentation, is:

Build & Run the app extension in the simulator and, when prompted for a host app, choose the specific app that you're going to call the extension from. In my case I was launching my Action extension from Safari by pulling up a share sheet on a PDF.

What wasn't working before was following other people's suggestions of using Today as the host but then leaving that app and going over to Safari to call my extension. I no longer even need to run my containing app first before running the extension.

From Apple's Documentation:

> In your extension scheme’s Run phase, you specify a host app as the executable. Upon accessing the extension through that specified host’s UI, the Xcode debugger attaches to the extension.

Solution 8 - Ios

I actually got the logs to run quite simply in Xcode 6.3. Firstly, build and run the containing app. Once the containing app is running on the device, build and run the app extension by changing the scheme to the app extension.

Apple has documentation directly related to debugging, profiling and testing your app extension.

Solution 9 - Ios

A trick which works for me (although it is quite an ugly one) is to place a dummy UILabel somewhere in the bottom corner of my extension. I usually call it logLabel. It is then possible to update the text of this label with any log statement that you want to get logged. Such approach is not very good if you need to log statements from instances of different classes. And, obviously, it clutters your UI.

However, if you have a fairly simple widget and you don't mind about slight cluttering of the UI this does the trick. I have tried all other solutions outlined in this discussion and, sadly, none of them worked for me.

Solution 10 - Ios

The only way debugging works for me is by selecting Debug->Attach To Process By PID or Name Then enter the PID not the extension name. You can find the PID by running the extension on a device, go to Window->Devices. Find your device and viewing the console. When you see the name of your extension, its followed by 5 digit number. That is the PID

I also put a bunch of NSLog's in the extension in order to find the PID as well. This is on xCode 7

Solution 11 - Ios

Encounter the same problem about extension for NSLog, and break points. I have fought it with many days.

Device log can be found as following image. It is at XCode -> Window -> Devices and Simulators.

After enter the Open Console, there is a search field at the top-right of dialog. I can apply filter rule in there. For example, a process name contains Notification key word, or process name must equal to the name of extension target, ex: equal to MyNotificationServiceExtension process name.

Device log

Solution 12 - Ios

As of Xcode 6 Beta 5, I've been able to use an actual device running iOS8 to debug my extension. Try running it on a device and select Safari to launch into

Solution 13 - Ios

Clearly something is broken in Xcode6-B5.

If I try to run a Photo extension on the Simulator I cannot see any Photos.app as an option for the extension attaching process.

debug options within simulator

The same, running on a real device, give me the correct behaviour.

debug options withing a real device

In the first case any breakpoint is not honorated. In the latter case, breakpoints work like a charm.

Solution 14 - Ios

You should know that the container app and extension are totally two difference process in iOS while the LLVM debugs only a thread a time, so when you are debugging, the console never log the extension and never stop at breakpoint.

You can solve most of the problems by @Vince Yuan's method.

However, my problem is that Xcode debugger hardly hook on my keyboard extension on both iOS Simulator and devices, like 1 time in 7-8 runs, It's totally a matter of probability. @Vince Yuan's method also work for just sometimes.

My little experience is that when you run you debug scheme, if the debug Session in the left panel showing that 'No Debug Session', there is no need to open your extension and test it, the debugger didn't hook on, just run again for lucky.

but when you see com.xxx.xxx.xxx is waiting to Attach, the extension can definitely get debugged.

This is a little trick for whom cannot debug iOS extension, especially keyboard extension.

Solution 15 - Ios

To overcome all the states caused by ever changing IDE, I'm using iOS Console by lemonjar.com – it displays a console window for any connected iOS device rendering syslog messages regardless the process ID. You can see both app and extension debug log messages at once here.

Solution 16 - Ios

I could debug my extension with the way I describe below:

  1. Xcode : Debug -> Attach to process by PID or Name. Your extension scheme name.
  2. Then select your main app target and run.

I hope it also works for you guys.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionohhoView Question on Stackoverflow
Solution 1 - IosVince YuanView Answer on Stackoverflow
Solution 2 - IosBalestraPatrickView Answer on Stackoverflow
Solution 3 - IosAndrewView Answer on Stackoverflow
Solution 4 - IosMasalisView Answer on Stackoverflow
Solution 5 - IosMaciek CzarnikView Answer on Stackoverflow
Solution 6 - IosJanoView Answer on Stackoverflow
Solution 7 - IosAndrewView Answer on Stackoverflow
Solution 8 - IosMichaelView Answer on Stackoverflow
Solution 9 - IosAndriy GordiychukView Answer on Stackoverflow
Solution 10 - IosTonyView Answer on Stackoverflow
Solution 11 - IosAechoLiuView Answer on Stackoverflow
Solution 12 - IosRich86manView Answer on Stackoverflow
Solution 13 - IosvalvolineView Answer on Stackoverflow
Solution 14 - IosHenryView Answer on Stackoverflow
Solution 15 - IosigraczechView Answer on Stackoverflow
Solution 16 - IosabdullahselekView Answer on Stackoverflow