[ios] iOS 10: "[App] if we're in the real pre-commit handler we can't actually add any new fences due to CA restriction"

I sometimes get this message in the logs of Xcode 8b3 when running my app, everything seems to work, but I'd like to know where this comes from. Google did not help at all.

Try putting the following in the environment variables for the scheme under run(debug)

OS_ACTIVITY_MODE = disable

in your Xcode:

• Click on your active scheme name right next to the Stop button
• Click on Edit Scheme....
• in Run (Debug) select the Arguments tab
• in Environment Variables click +
• add variable: OS_ACTIVITY_MODE = disable

It comes from +[UIWindow _synchronizeDrawingAcrossProcessesOverPort:withPreCommitHandler:] via os_log API. It doesn't depend from another components/frameworks that you are using(only from UIKit) - it reproduces in clean single view application project on changing interface orientation.

This method consists from 2 parts:

1. adding passed precommit handler to list of handlers;
2. do some work, that depends on current finite state machine state.

When second part fails (looks like prohibited transition), it prints message above to error log. However, I think that this problem is not fatal: there are 2 additional assert cases in this method, that will lead to crash in debug.

Seems that radar is the best we can do.

OS_ACTIVITY_MODE = disable

This will also disable the ability to debug in real devices (no console output from real devices from then on).

We can mute it in this way (device and simulator need different values):

Add the Name OS_ACTIVITY_MODE and the Value ${DEBUG_ACTIVITY_MODE} and check it (in Product -> Scheme -> Edit Scheme -> Run -> Arguments -> Environment).

Add User-Defined Setting DEBUG_ACTIVITY_MODE, then add Any iOS Simulator SDK for Debug and set it's value to disable (in Project -> Build settings -> + -> User-Defined Setting)

To fix, I deleted the app from Simulator.

I also ran Clean first.

I do not think anything orientation-related triggered it. The biggest thing that changed before this symptom started is that a Swift framework started calling NSLog on worker threads instead of main thread.