Post not yet marked as solved
I'm not sure, if it's the same problem or not, but I also faced problems with failing swipes in UI tests (in iOS simulator): at least in certain cases (like swipeLeft() to reveal the standard "accessory menu" on a table row), they behave like clicks. I was able to pinpoint it to running x86_64 build of UI tests on M1 (adding ARCHS=x86_64 to xcodebuild arguments). With the very same native build on M1, swipes in UI tests behave as expected.
Just in case, I'm reproducing it on Xcode 13.4.1 and iOS simulator for iPhone 8 running iOS 15.2. Will check most recent iOS 15.5 a bit later.
Move your DerivedData to a path that is short enough. E.g. to /tmp. That was a solution that worked for us/seems to be related to paths hard-coded in LC_PATH load commands or something like that (take a look at otool -l <your mach_o executable> output).
Post not yet marked as solved
I'm not sure whether that's your case or not, but I faced it with Git pre-push hook. The issue was caused by the fact that GIT_DIR was set to the "source" directory, and, as far as I understand, that's something that affects git checkouts that are done during xcodebuild. (It clearly looks like a xcodebuild bug to me, that supposedly does git clone followed by git checkout, with the latter unexpectedly impacted by GIT_DIR).
I'm able to reproduce it by doing something like below (with clean DerivedData):
env GIT_DIR="$PWD/.git" xcodebuild -disableAutomaticPackageResolution ...
The remedy in my case was to unexport GIT_DIR for the invocation of xcodebuild, like below:
env -u GIT_DIR xcodebuild -disableAutomaticPackageResolution ...
Wondering if something similar happens with GIT_DIR in your setup.
Post not yet marked as solved
Just to mention it, we observed some problems on iOS 15 and employed the workaround with attaching the view IDs to the views at top level. However, immediately after that we realized that it makes sense even from UX perspective: considering e.g. the case of scrollable section with title, it makes sense to scroll to the section as whole rather to the title of the section, as it makes difference when there's not enough content below the section to scroll it to the top: in that scenario, attaching the id to the section makes the whole section rather just the title scrolled into in the view.
In our case it looks like it's an issue with lack of background fetch capability that results in watchdog killing the app. We're able to reproduce it with the steps in https://github.com/firebase/firebase-ios-sdk/issues/3759
Just in case, we're observing similar crashes, involving CLConnectionClient, however we also see some crashes not involving CLConnectionClient:Crashed: com.apple.runningboardservices.connection.incoming
0 libdyld.dylib 0x18c828684 dyld3::closure::ObjCStringTable::hash(char const*, unsigned long) const + 16
1 libdyld.dylib 0x18c828c98 dyld3::closure::ObjCStringTable::getIndex(char const*) const + 52
2 libdyld.dylib 0x18c828b18 dyld3::closure::ObjCClassOpt::forEachClass(char const*, dyld3::Array<std::__1::pair<unsigned long, unsigned long> > const&, void (void*, bool, bool*) block_pointer) const + 52
3 libdyld.dylib 0x18c8354c4 dyld3::AllImages::forEachObjCClass(char const*, void (void*, bool, bool*) block_pointer) const + 132
4 libobjc.A.dylib 0x18c767c38 getPreoptimizedClass + 148
5 libobjc.A.dylib 0x18c7528d8 getClassExceptSomeSwift(char const*) + 20
6 libobjc.A.dylib 0x18c753784 look_up_class + 100
7 Foundation 0x18cde52ec NSClassFromString + 200
8 BaseBoard 0x18f5c0b2c _BSXPCDecodeObject + 2000
9 BaseBoard 0x18f5be49c _BSXPCDecodeObjectForKey + 288
10 RunningBoardServices 0x18f55976c -[RBSXPCMessage decodeArgumentCollection:withClass:atIndex:allowNil:error:] + 416
11 RunningBoardServices 0x18f545da8 __32-[RBSConnection _handleMessage:]_block_invoke_2.337 + 92
12 libsystem_trace.dylib 0x18c5d3708 _os_activity_initiate_impl + 56
13 RunningBoardServices 0x18f5459d0 -[RBSConnection _handleMessage:] + 784
14 RunningBoardServices 0x18f5464fc __30-[RBSConnection _lock_connect]_block_invoke + 88
15 libxpc.dylib 0x18c5f258c _xpc_connection_call_event_handler + 68
16 libxpc.dylib 0x18c5f2904 _xpc_connection_mach_event + 876
17 libdispatch.dylib 0x18c6f128c _dispatch_client_callout4 + 16
18 libdispatch.dylib 0x18c6adc64 _dispatch_mach_msg_invoke$VARIANT$mp + 380
19 libdispatch.dylib 0x18c69d3f0 _dispatch_lane_serial_drain$VARIANT$mp + 300
20 libdispatch.dylib 0x18c6ae864 _dispatch_mach_invoke$VARIANT$mp + 472
21 libdispatch.dylib 0x18c69d3f0 _dispatch_lane_serial_drain$VARIANT$mp + 300
22 libdispatch.dylib 0x18c69df48 _dispatch_lane_invoke$VARIANT$mp + 468
23 libdispatch.dylib 0x18c6a7400 _dispatch_workloop_worker_thread + 588
24 libsystem_pthread.dylib 0x18c740fa8 _pthread_wqthread + 276
25 libsystem_pthread.dylib 0x18c743ae4 start_wqthread + 8
Hey, adamup928, just in case, we're observing the similar issue and yes, we're using Firebase SDK
