It turns out that if you don't ensure that XCTestObservationCenter has already loaded, then attempting to use it and add an observer subverts some sort of internal setup required to get XCTest to spit out log lines during your tests like this:

Test Case -[MyTestTarget.testOne testMethodOne] started.

This is a really big problem if you rely on something like xcpretty parsing this output from XCTest to later generate a test report. To fix this, I moved any loading that KIF needed from a +(void)load method, into +[KIFTestCase setUp]. This fixed the issue, and now all of our important XCTest logging is back.

Things I tried that didn't work:

1. Doing the setup in +[XCTestObservationCenter initialize] (not a good idea for other reasons, but I tried anyway)
2. Doing the setup in a function with __attribute__(constructor)
3. Moving the setup into +(void)load on XCTestObservationCenter. This appeared to work initially, but this didn't work when switching from using KIF as a static library to using it as a dynamic framework. So, I added a dispatch_async, and this appeared to work in every case. But, I found with further testing that enabling accessibility here wasn't nearly as reliable as enabling it in the XCTestObservation method (as it was previously).

Here are the docs on +(void)load for reference:

Invoked whenever a class or category is added to the Objective-C runtime; implement this method to perform class-specific behavior upon loading.

The load message is sent to classes and categories that are both dynamically loaded and statically linked, but only if the newly loaded class or category implements a method that can respond.
The order of initialization is as follows:

1. All initializers in any framework you link to.
2. All +load methods in your image.
3. All C++ static initializers and C/C++ __attribute__(constructor) functions in your image.
4. All initializers in frameworks that link to you.

In addition:

• A class’s +load method is called after all of its superclasses’ +load methods.
• A category +load method is called after the class’s own +load method.
  In a custom implementation of load you can therefore safely message other unrelated classes from the same image, but any load methods implemented by those classes may not have run yet.

I also went ahead and applied similar treatment I initially applied to the KIFAccessibilityEnabler setup, wherein I moved it into the + (void)load method on XCTestObservationCenter because that's the class it needed to use (i.e. attempt 3 above), to the UIApplication swizzling as well. In this case, we'd also want to also be sure that the UIApplication class is loaded in the runtime before interacting with it.