UI tests on iOS15 is launching but not executing tests

I am seeing the same behaviour. Strangley UITest run fine with a couple of minor differences from XCode 12. But Unit tests compile and just block the simulator and won't run eventually timing out.

XCode 13 RC, on Big Sur 11.6

I'm having the same issue. Unit tests compile successfully but don't run and eventually time out. Have you had any luck with this?

No luck so far, I get a spindump which is a bit tricky to read after it fails. Not sure if Eskimo is about to help answer this?

When I run against a iOS 14 simulator or less it works fine

Not sure if Eskimo is about to help answer this?

Probably not )-:

If you create a new project from one of the built-in templates, does it show the same problem.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I think it's a bit tricker than that unforunately. I can get you a spindump file of our project deadlocking during testing if that will help. I think it's also happening during normal function of the app too, users are reporting being stuck on a screen before the splash and the UIApplicationDelegate callbacks didFinishLaunchingWithOptions are never called. Looks like a UIKit bug causing a deadlock.

I'm using Texture as a pod and I believe the deadlock is happening during some initialisation code where UIKit is called to create a layer. Looks like the deadlock is happening inside UIKit

https://github.com/TextureGroup/Texture/issues/2029

I have a spindump of the running simulator after the tests timeout if it'll help Eskimo

Without a good understanding on how to analyse spin dumps. I see this at the bottom of the main apps running. It looks like two threads are waiting on each other and causing the deadlock

(blocked by turnstile waiting for AppName [66373] [unique pid 463253] thread 0x8ffc2e) 1-204

drive.google.com/file/d/1KhdlKf5v77cVuiOQ-T1ZUGSKrVLobCzs/view?usp=sharing

Hmmm, that’s not good. Consider this:

204  invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 182 (dyld_sim + 59545) [0x10e9ca899] 1-204
204  ASLoadFrameworkInitializer() + 9 (ASDisplayNode.mm:260,3 in BlinkKit + 25008201) [0x11ad99849] 1-204

[I’ve unindented the spin dump so that it’s easier to read here.]

The dynamic linker is calling a framework initialiser function for BlinkKit. Now this:

204  __ASInitializeFrameworkMainThread_block_invoke + 371 (ASInternalHelpers.mm:73,25 in BlinkKit + 25314563) [0x11ade4503] 1-204
204  -[UIView init] + 44 (UIKitCore + 19218368) [0x13e685fc0] 1-204

That framework initialiser is creating a new UIView. That’s a way more heavyweight operation than I’d be comfortable doing in a framework initialiser.

And if you look at secondary threads you can see why:

204  dyld4::APIs::dlopen_from(char const*, int, void*) + 271 (dyld_sim + 105815) [0x10e9d5d57] 1-204

204  dyld4::APIs::dlopen_from(char const*, int, void*) + 271 (dyld_sim + 105815) [0x10e9d5d57] 1-204

They are both blocked waiting for the dynamic linker lock.

So, framework initialisers are problematic for a whole range of reasons. In this specific case it seems that the significant dynamic linker and iOS framework changes we made in iOS 15 are causing your initialiser to trigger a deadlock. It’d be reasonable for you to file a compatibility bug about that (although, frankly, that bug would have been a lot more welcome back in June). However, my advice — and this is both as a workaround and as a long-term direction — is that you ditch your framework initialisers entirely, and instead do this stuff lazily as part of your general app startup sequence.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Many thanks Eskimo I will have a dig into this further. This is part of a popular UI library called Texture so I don't imagine I'm the only one facing issues with the framework initialiser and the workaround resides in a third party library.

I have reported FB9647954

I looked at spindump file which got generated when tests failed to execute. It mentioned something about a pod SDK which was added as dependency. It needed an updated version. I suggest update dependent frameworks.

I looked at spindump file which got generated when tests failed to execute. It mentioned something about a pod SDK which I have added as a dependency (hard to read but just go through the names of your frameworks and check if you find any resembling one). It needed an updated version for it. I suggest update dependent frameworks/pods etc.

This was also happening to us! It turned out to be a race condition in one legacy code we had executing on a +(void) load method that was calling another module (presumably) before that module was loaded.. this code used the filesystem to fetch some info to put on a ui component later. still unsure on why this only happens on iOS 15 tho, I couldn't find documentation about changes on how dynamic libs are loaded on iOS 15

This is the method in our case at least, that was being called on a load Obj-C Method imageWithContentsOfFile https://developer.apple.com/documentation/uikit/uiimage/1624123-imagewithcontentsoffile

I am using macOS Big Sur and Xcode 13.1 (Release), and got this issue. UI Test works perfectly but Unit Test is not running any test. It launches simulator and then hang and only showing white screen. I also using Texture in cocoapods. No such error in Xcode 12. So, what is the solution?

Same problem...

Sipndump file pointed to us that something wrong with at linking stage.

Experimentally we found the reason: YandexMapsMobile framework version 4.0.0-lite https://yandex.com/dev/maps/mapkit/.

UnitTest stuck fixed by deleting YandexMapsMobile from project.

Apple, however, what happened with dynamic linker under iOS 15 Sim?!

We found workaround!

Two workarounds!

First:

In our case in TheApp has InternalProjectDependency which depends on external dependency that cause deadlock.

We add Environment Variable DYLD_INSERT_LIBRARIES in to test buld scheme with value $(BUILT_PRODUCTS_DIR)/TheApp.app/Frameworks/InternalProjectDependency.framework/InternalProjectDependency

Second:

Just use TestPlans;)