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"
@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.