4 Replies
      Latest reply on Feb 17, 2017 2:52 PM by eskimo
      davidp_navdy Level 1 Level 1 (0 points)

        Environment: OS X macOS Sierra 10.12.2, Xcode 8.2.1, iPhone 7 running 10.2, app written in Swift.


        I'm having a chronic problem where log messages from my app only show in the Xcode log window the first time I run the app after booting the phone.


        If I rebuild and run the app again, the messages don't appear.


        The issue persists whether I use NSLog or Swift's print statement to print the messages.  If I use NSLog they show up in the Console app, and that's an OK workaround - except one of the third-party libraries I use apparently uses "print" or equivalent to write messages to stdout/stderr.


        Has anyone else seen this issue? It's pretty chronic across my team here; I'm surprised I haven't seen other messages about it...



        • Re: Print/NSLog messages not showing on second run
          jakej-navdy Level 1 Level 1 (0 points)

          I'm having the same issue with the exact same setup.

          • Re: Print/NSLog messages not showing on second run
            eskimo Apple Staff Apple Staff (13,895 points)

            If I rebuild and run the app again, the messages don't appear.

            Does an unplug/replug of the device clear the problem?

            Also, if you create a small test app does the problem occur there?  Or is it only affecting your real app?

            Does it affect the simulator?

            Share and Enjoy

            Quinn “The Eskimo!”
            Apple Developer Relations, Developer Technical Support, Core OS/Hardware
            let myEmail = "eskimo" + "1" + "@apple.com"

            • Re: Print/NSLog messages not showing on second run
              davidp_navdy Level 1 Level 1 (0 points)

              @eskimo thanks for chiming in, sorry I missed it!


              In any case, we figured out what was going on.


              Our app works with an MFi Accessory via Bluetooth. That accessory will, by default, close and re-open the Bluetooth RFCOMM connection if it detects application-level connection, i.e. EASession, has gone away. When it re-opens, iap2d re-launches our app - we have the "external-accessory" background mode set.


              This led to a race condition when re-starting the app via Xcode: the new build would get copied over, but then get launched by MFi before Xcode got a chance to launch it. This meant that any command-line arguments from our Xcode scheme didn't apply, and Xcode didn't get a chance to grab stdout/stderr from our process.


              Oddly, Xcode was able to get the debugger attached. So we could still set breakpoints, etc. Just couldn't see the logs.


              The fix for us was to add a flag in our accessory which makes it not re-connect automatically, but wait for the connection from the phone when the app launches.


              So! Issue resolved, and likely pretty obscure for most developers - although it could happen to anyone whose app can launch in the background in response to events like push notifications, etc. Just happened more often for us.


              BTW, the new Console app in Sierra is what allowed us to finally figure this out - we were able to better see the log messages from iap2d to see that the app was launching without Xcode's involvement.