I pushed the whole test project here: https://github.com/Uncommon/CollectionViewDragTest

I filed a bug report for this as FB16451771, including a sample project.

I have tried these workarounds: Install my own pan gesture recognizer to help detect when shouldBeginMultipleSelectionInteractionAt is being called for an actual two finger swipe. But in the delegate callback, I don't see that the gesture recognizer has triggered. In the callback, examine the collection view's list of gesture recognizers and return false if any one-finger gestures have triggered. This did not work very consistently.

The solution I ended up going with is the app opens a socket to listen on, writes out the port it got to a file in SIMULATOR_SHARED_RESOURCES_DIRECTORY, and the test runner reads that file and connects to the port. I tried using a unix domain socket, but (as the app itself is in C#) the .NET API for that kept throwing PlatformNotSupportedException. I really don't know if there was a real error or if .NET just thinks iOS doesn't support domain sockets. My approach did still require adding an entitlement, so I'll just have to modify my build script to only include that in the debug build.

The problem I was running into with my macro turns out to be a compiler bug: https://github.com/apple/swift/issues/69073

The workaround, of course, is to temporarily copy the expansion into the actual code and comment out the macro expansion.

For the record, the culprit ended up being WKUserContentController.add(_:name:) creating a retain cycle. Once I fixed that, the entire window contents got released properly.

My reason for using SecKeychainCreate/Delete is for testing purposes- I want to test my keychain code without affecting my actual keychain, so I create a temporary one for the duration of the test.

I'm having this issue too, regardless of device or signing settings. Edit: Selecting a physical device as the destination does indeed make the errors go away.

It looks like I've solved the problem by saving the separator item when I see it in toolbarWillAddItem, and then returning it from toolbar(_:itemForItemIdentifier:willBeInsertedIntoToolbar:) to avoid having a new instance created. That way, removing and re-adding the item works without having exceptions thrown. The last little snag was to not remove and re-add the separator blindly. The window state may have been preserved across app launches, so I needed to not make assumptions about how the window would initially appear.